For me, as a user - this doesn't quite make any sense. It's super hard for me to reason about what kind of runtime behavior this is supposed to represent. I've also checked it with this PR and this creates an unsoundness and might lead to runtime errors like here:

function test<T, K extends keyof T>(t: T, k: K) {
    return t[k]; // oops, runtime error if we allow the call below
}

test(null, 'foo') // OK with this patch, error with 4.7

Given the new 4.8 behavior, test itself should have an error in its implementation due to not having a { } constraint.

First experiment wasn't optimal, now deferring types like keyof (T & {}) such that effects of removing undefined and null are properly reflected.

Isn't this sort of an unusual thing to "defer" the error reporting to the call site? I'm not totally sure what I think about this yet but my first thought was that it's a special case in the algorithm that might be hard to explain to people.

I guess this build on top of the fact that T[never] is always OK and never is always assignable to everything so perhaps this fits the existing rules just OK. I'll take consolation in the fact @RyanCavanaugh's first instinct was that those should raise errors too 😅

I added the test and the comment to capture the behavior for future reference. It's nothing new actually. We have the same behavior in 4.7 with the old NonNullable<T> based on a conditional type. This PR ensures we carry it forward in 4.8 with NonNullable<T> based on T & {}.

Sure - but I'm not thinking here from the PoV of NonNullable at all. My confusion/concern was solely about unconstrained generics and your changes from #49119, I've assumed that given those changes this indexed access would error nowadays. Since the base constraint of unconstrained T is unknown it feels off that we can use indexed access on it without refining the type somehow first

It may seem surprising at first, but it is actually quite meaningful because we can permit t[k] without requiring local proof that t is non-undefined and non-null. Such proof would add unnecessary overhead for instantiations where the type argument for T is already known not to be undefined or null.